refactor(rpc/get_account): batch storage map proofs - #2439
Conversation
GetAccount now returns a PartialSmt with all requested key-value pairs. - A request for explicit map keys always returns one partial SMT covering those keys. - Partial SMTs are scoped to one storage map at one block. Proofs from different maps or roots are never merged. - The response carries the original, unhashed `StorageMapKey`s. The SMT contains hashed keys, so the raw keys cannot be recovered from the tree. - Values are not duplicated outside the SMT. A client obtains a value by hashing the raw key and calling `PartialSmt::get_value()`. - `too_many_entries`, `all_entries`, and `partial_map` become mutually exclusive results. - The removed `entries_with_proofs` field number and name are reserved. Even though compatibility is intentionally broken, reusing the field could make an old client try to decode the new length-delimited message as the old one. - The compact protobuf representation mirrors `miden_crypto::merkle::smt::UniqueNodes`. Do not encode `PartialSmt` as an opaque byte string.
5ae4953 to
1a99dc6
Compare
|
Looks like there is a bug in |
Once 0xMiden/miden-vm#3471 is merged, we should be able to do a patch release and it'll flow through to here immediately. |
|
@igamigo Do you have an estimate on how many storage keys a client usually requests from a storage map in a single As far as I understand there are two cases where the client is requesting specific keys from a storage map:
As far as I understand in the lazy (execution) use case the client is always requesting a single key from a single storage slot. There is nothing to be gained in that case from the optimization this PR implements. In the first case though: how much this optimization helps depends on the number of the storage map keys typically required. Do we have an estimate on how many keys we're expecting there? |
2 participants
Summary
GetAccount now returns a PartialSmt with all requested key-value pairs.
StorageMapKeys. The SMT contains hashed keys, so the raw keys cannot be recovered from the tree.PartialSmt::get_value().too_many_entries,all_entries, andpartial_mapbecome mutually exclusive results.entries_with_proofsfield number and name are reserved. Even though compatibility is intentionally broken, reusing the field could make an old client try to decode the new length-delimited message as the old one.miden_crypto::merkle::smt::UniqueNodes. Do not encodePartialSmtas an opaque byte string.Closes #617
Changelog